1. Field of the Invention:
The invention relates to security in mobile communication systems. Particularly, the invention relates to the delivery of root certificates to users from their home networks depending on the current network of the user.
2. Description of the Related Art:
In mobile systems security is a vital part of network and mobile terminal functionality. Due to the fact that mobile terminals may roam freely in different networks, it is necessary to establish trusted relationships between the mobile terminals and the networks, which are currently serving the mobile terminals. The trusted relationship involves that the mobile terminal and the visited network have performed mutual authentication and are prepared to use data encryption and integrity protection. As a mobile terminal roams in different network there may arise a need to establish a security association from the mobile terminal to a gateway, which provides access to a network already trusted by the mobile terminal. The network that is already trusted may be, for example, a corporate Intranet. The network that is trusted may also be an Internet segment via which it is possible to establish a trusted connection to a remote client or a remote network, which may be, for example, a corporate Intranet.
The establishing of Security Associations (SA) between a pair of hosts, between a host and a security gateway or between two security gateways is discussed in the Internet Engineering Task Force (IETF) IP security architecture (IPsec) standard, namely Request For Comments (RFC 2401). The IPsec architecture relies on the security protocols Authentication Header (AH) and Encapsulation Security Payload (ESP), which are natively present in IPv6 and also available in IPv4. The IPsec relies on two types of databases, namely a Security Policy Database (SPD) and a Security Association Database (SAD). The SPD defines the criteria based on which given packets are assigned to a given SA. The SAD describes the parameters associated with a given SA such as the algorithms and the keys used. An SA is established either manually at the request from a user or automatically as a packet is determined to be associated with an SA, which does not currently exists. The establishing of security associations is performed using Internet Key Exchange (IKE) protocol. The current version of IKE is IKE version 2, which is described, for example, in the IETF document draft-ietf-ipsec-ikev2-17.txt.
The IPsec architecture is especially useful in Wireless Local Area Networks (WLAN) where it is necessary to establish a security association between a mobile terminal and a gateway located in the current visited network of the mobile terminal. The gateway is used to access a trusted second network. The second network is, for example, a corporate Intranet or another trusted network. The security association establishment may be performed in association with the authentication of the mobile terminal to the network. The authentication of a mobile terminal to the network is described, for example, in 3rd Generation Partnership Project (3GPP) specification TS 33.234 V6.0.0 (2004-03). During the authentication of the mobile terminal to its home network and the authentication of the home network to the mobile terminal, it is also necessary to authenticate the gateway, which is used as an access point to the second network. Otherwise it would be possible to perform a man-in-the-middle attack by using a false gateway and to record data, which is later used in a playback type of attack.
Reference is now made to FIG. 1, which illustrates a mobile node communicating via a gateway with a remote host in a Wireless Local Area Network and Mobile Communication System interworking scenario in prior art. In FIG. 1 there is an IP network 120, to which a gateway 114 and a remote host 122 are connected. Between gateway 114 and the remote host there exists a security association 124, which carries traffic from gateway 114 to remote host 122 securely over the IP network. Mobile node 100 communicates with gateway 114 using a Wireless Local Area Network (WLAN) 110. WLAN 110 coverage area is served by at least a base station 112. With WLAN 110 is also associated an Authentication, Authorization and Accounting (AAA) proxy 116. AAA proxy communicates with gateway 114 using, for example, RADIUS (Remote Authentication Dial-In User Service) or DIAMETER (Diameter Base Protocol) protocols. RADIUS protocol is defined in the IETF document RFC 2865 and DIAMETER protocol in RFC 3588. AAA proxy 116 communicates also with an AAA server 132, which is in association with a network 130, which is the home network of mobile node 100. AAA server 132 in turn accesses a Home Location Register (HLR) 134 in order to obtain authentication and encryption information associated with mobile node 100. The authentication and encryption information are actually stored in an Authentication Center (AuC) in association with HLR 134. Hereinafter, the AuC functionality is not separately discussed, but considered as part of an HLR such as HLR 134.
Reference is now made to FIG. 2, which illustrates Extensible Authentication Protocol (EAP) authentication and key agreement signaling followed by IKEv2 security association initialization in prior art. It should be noted that the signaling is also applicable in the case of EAP Subscriber Identity Module (SIM) authentication. Extensible Authentication Protocol (EAP) is defined in IETF document RFC 2284. The purpose of the signaling is to mutually authenticate mobile node 100 and AAA server 132, which represents the home network of mobile node 100, and to mutually authenticate mobile node 100 and gateway 114. FIG. 2 also elucidates the problems involved with the checking of the certificate of gateway 114.
At time t1 mobile node 100 possesses a Certification Authority (CA) certificate, in other words a root certificate, which is used to verify other certificates. The possession of CA certificate is required before other certificates may be trusted. A Certificate Authority signs all certificates that it issues with its private key. The corresponding Certificate Authority public key is itself contained within a certificate, called a CA certificate. Mobile node 100 must contain this CA certificate in its trusted root library in order to trust certificates signed by the CA's private key. The trusted root library comprises all CA certificates. The certificates for other entities are needed to verify signatures produced by peer entities communicating with the mobile node 100. Mobile node 100 may need to possess a number of CA certificates, because different entities communicating with mobile node 100 may use different certification authorities to sign their public keys. For example, different gateways in different WLANs may have certificates, which have been certified by different CAs. Therefore, before establishing communication with gateway 114 mobile node 100 must obtain the CA certificate used by gateway 114. In prior art CA certificates have been manually configured to mobile nodes. This involves that the CA certificate is delivered to mobile node on a smart card such as a Subscriber Identification Module (SIM) provided by the home network operator. The mobile node user may also manually download the CA certificates to mobile node 100. As the user subscription is activated, the home network may also decide to push a number of CA certificates to mobile node 100 before any secure communication is to be initiated by mobile node 100. The disadvantage of these solutions is that mobile node 100 needs a multitude of CA certificates, of which only a few are actually used. Besides, CA certificates essential for enabling secure communications via a visiting network may be missing from the CA certificates possessed by mobile node 100 when it is brought to the visited network. It may not be possible to obtain all CA certificates in advance to mobile node 100.
At time t1 mobile node 100 starts security association initiation using IKE. A WLAN connection exists between mobile node 100 and gateway 114. In IKE initiation phase mobile node 100 sends IKE_SA_INIT message to gateway 114 as illustrated in FIG. 2 with arrow 201. The message comprises IKE header, the public Diffie-Hellman value of mobile node 100, algorithms proposed by mobile node 100 and a first nonce, which is a non-repeating random value, that is, nonsense. Gateway 114 responds by sending IKE_SA_INIT message as illustrated with arrow 202. The message comprises IKE header, the public Diffie-Hellman value of gateway 114, the algorithms selected by gateway 114 a second nonce selected by gateway 114.
In IKE authentication phase mobile node 100 sends IKE_AUTH message comprising its identity MS-Id, a value that authenticates mobile node 100 and verifies that mobile node 100 was the sender of the earlier IKE_SA_INIT message, algorithms proposed by mobile node 100 for authentication and a traffic specification, which provides information on source and destination IP addresses for the security association. The message is illustrated with arrow 203. Gateway 114 sends an EAP Response/Identity message comprising MS-Id to AAA proxy 116, which is encapsulated, for example, in a DIAMETER packet. The message is illustrated with arrow 204. AAA proxy 116 routes to the proper AAA server based on the realm part of the Network Access Identifier (NAI). The MS-Id is comprised in the NAI. The realm part identifies the home network of mobile node 100. AAA proxy 116 sends EAP Response/Identity message to AAA server 132 as illustrated with arrow 205. AAA server 132 checks if it has an unused authentication vector for mobile node 100. If there is no unused authentication vector, AAA server 132 sends mobile node 100 identity MS-Id to HLR 134 as illustrated with arrow 206. HLR 134 responds with at least one authentication vector as illustrated with arrow 207. The authentication vectors comprise at least a random value RAND, an expected response value XRES, a Ciphering Key (CK), an Integrity Key (IK), an authentication token AUTN. Thereupon, using at least the received random value RAND AAA server 132 computes a Master Session Key (MSK). In one embodiment of the invention, the MSK is computed using the received CK and IK. However, it should be noted that CK and IK have earlier been computed from the RAND value using the secret key K in an AuC in association with HLR 134.
AAA server 132 forms an EAP Request/AKA-Challenge message comprising the RAND and AUTN values, a protected pseudonym for mobile node 100 and a next re-authentication identity. The acronym AKA stands for Authentication and Key Agreement. The message is protected using a MAC value, which is generated using a secure hash algorithm with the MSK as the key. Thereupon, AAA server 132 sends the EAP Request/AKA-Challenge message to AAA proxy 116 as illustrated with arrow 208. AAA proxy sends the EAP Request/AKA-Challenge message to gateway 114.
At time t2 gateway 114 includes its own certificate (GW-cert), which has been signed by a CA, and the EAP Request/AKA-Challenge message contents in IKE_AUTH message. Gateway 114 also signs the IKE_AUTH message, which is illustrated in FIG. 2 as the “sign” parameter, and sends the IKE_AUTH message to mobile node 100 as illustrated with arrow 210.
At time t3 after receiving the message 210, mobile node 100 verifies that the signature “sign” in message 210 is correct by using the public key of gateway 114. The public key of gateway 114 is provided, for example, in the certificate (GW-cert) of gateway 114 that it just sent. The validity of the certificate of the gateway is checked by mobile node 100. Mobile node 100 verifies that the certificate of the gateway has been signed by CA, for example, so that mobile node obtains the CA public key from the CA certificate and compares a first message digest computed from the certificate of the gateway to a second message digest obtained by decrypting the CA signature using CA public key. Thereupon, mobile node 100 forms its Master Session Key (MSK) using at least the RAND value obtained in message 210 to it. The derivation may involve first deriving an IK value and a CK value from the RAND value using the secret key K. Thus, the MSKs in mobile node 100 and AAA server 132 should be the same. Mobile node 100 computes a RES value using the secret key K shared by it and HLR 134. Mobile node 100 includes the RES value in an EAP Response/AKA-Challenge message. Mobile node 100 also computes a MAC value, which is included in the message. The message is protected using the MAC value, which is generated using a secure hash algorithm with the MSK as the key. Mobile node 100 sends the message as illustrated with arrow 211. The message is further sent by gateway 114 to AAA proxy 116 and by AAA proxy 116 to AAA server 132 as illustrated with arrows 212 and 213.
At time t4 after the receiving of message 213 AAA server 132 verifies the MAC value using MSK. AAA server 132 also compares the provided RES value to the XRES value in the current authentication vector, namely the authentication vector from which corresponding RAND value was earlier sent by AAA server 132. If the comparison proves successful, AAA server 132 sends an EAP Success message to AAA proxy 116 as illustrated with arrow 214. If some extra keying material is required for WLAN technology specific confidentiality and/or integrity protection, AAA server 132 includes it into the packet carrying EAP success message. AAA server 132 includes the keying material in the underlying AAA protocol message, not in the EAP level message. AAA proxy 116 forwards the message to gateway 114, which sends the message further to mobile node 100, as illustrated with arrows 215 and 216.